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Abstract We present an embedding of Petri nets into B abstract systems. The 
embedding is achieved by translating both the static structure (modelling aspect) 
and the evolution semantics of Petri nets. The static structure of a Petri-net is cap- 
tured within a B abstract system through a graph structure. This abstract system is 
then included in another abstract system which captures the evolution semantics 
of Petri-nets. The evolution semantics results in some B events depending on the 
chosen policies: basic nets or high level Petri nets. The current embedding enables 
one to use conjointly Petri nets and Event-B in the same system development, but 
at different steps and for various analysis. 

Keywords: B System, Petri-Nets, Embedding Techniques, Method and Tool Integration 

1 Introduction 

Reliable system development requires the use of concepts, languages, tools and methods 
which are provided by formal approaches. Several mono-paradigm methods akeady ex- 
ist. However, real size systems often overwhelm the scope covered by mono-paradigm 
specification techniques and their complexity requires an adequate integration of ap- 
propriate techniques and methods for both the development and the formal analysis. 
Current research efforts focus on the combination of various approaches and their spe- 
cific tools in order to strengthen their impact on industrial system treatment. Therefore, 
there are some requirements to make formal methods more practical and efficient in 
their usage: i) they should be linked with engineering practices and techniques; ii) their 
mechanization by providing powerful and operational development tools. These points 
are still some challenges for the formal method community and therefore they motivate 
our work. 

The integration of different formal methods may be motivated by different kind of 
combinations: the complementarity of methods so as to cover the facets of the applica- 
tion at hand, the need of specific techniques such as composition and refinement, or spe- 
cific reasoning techniques such as theorem proving and model checking, or pragmatic 
considerations such as graphical formalisms and the interoperability of tool supports. 

In the current work we study the integration of Petri nets and B in order to use con- 
jointly both approaches in the same development. The motivation is to benefit from the 
complementarity of both approaches. Petri nets formalism may be used as a graphical 
front-end of a B development project. The B framework may follow to complement 
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formal analysis of the system modelled using Petri nets. 

On the one hand, Petri nets formalism are widely used L17I19I18I14I by engineers and 
also in academic or research projects. Petri nets also have graphical facilities, simulation 
and liveness property verification facilities via powerful model checking techniques. On 
the other hand, B is a model-based approach which permits correct development with 
refinement from abstract specifications to executable codes; it is based on theorem prov- 
ing technique and it offers (mainly) safety properties verification facilities. 

The contribution of this article resides in i) the definition of a (B) generic structure 
to capture Petri nets models and semantics; ii) the means to systematically embed Petri 
nets structure and their evolution rules into Event-B. This leads to the development of 
a bridge between Petri nets and B. 

The article is organised as follows: in Section 2 we introduce the Petri nets for- 
malism and the B Systems approach. Section 3 is devoted to the stepwise embedding 
of Petri nets into B: basic nets are first considered and then generalized to high level 
nets. Section 4 gives some issues related to analysis and in Section 5 we give some 
concluding remarks. 



2 Petri Nets and B Systems 

2.1 An Overview of Petri Nets (P-nets) 

Formally, a P-net is a 4-tuple {P, T, Pre, Post) where : 

- P is a finite set of places , (with | -P | = m, the cardinal of P); 

- T" is a finite set of transitions, (with | T \ = n, the cardinal of T); 

- P and T are disjoint sets (P n T = {}); 

- Pre : P X T — > N is an input function, Pre{p, t) denotes the number of arcs 
from the place p to the transition t; 

- Post : P X T ^ N is an output function, Posi(p, t) denotes the number of arcs 
from the transition t to the place p. 

Practically, a P-net is a bipartite directed graph whose arcs connect nodes from two 
distinct sets; the set of places and the set of transitions. Petri nets are equipped with a 
graphical formalism where the places are connected to the transitions using the directed 
arcs. 

Graph associated to a P-net. The graph associated to a net N is described by: 

- Fp the transitions reachable from each place: 
Vp e P-Ppip) ^ {t e T \ Pre{p, t) > 0} 

- Pf the places reachable from each transition: 

Wt e T.Ptit) = {p e p I Post{p, t) > 0} 

- the weight of each input arc: V p E P,yt e T . Wm{p, t) = Pre{p,t) 
and 

- VFout the weight of each output arc: V p e P,y t e T. Wout{p, t) = Post{p,t) 
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The graph associated to a P-net is the abstract representation which is used to manip- 
ulate the net. The places connected to a transition with an arc from each place to the 
transition are the input places of the transition. The places connected to a transition with 
an arc from the transition to each place are the output places of the transition. 

P-net Marking. A marked net Mm = {N, fi) is made of a net and a mapping 

^^ : p ^n. 

IJ,{p) is the number of tokens within p; it is called the marking of the place p. The initial 
marking Mq of a net is the n-tuple made of the initial marking of aU the places pi of the 
net: Mq = {^{pi), ■ • • , /i(pm)) where m is the number of places. 

Behaviour of a P-net. A P-net evolves by firing some enabled transitions. A transition 
is enabled if all its input places contain at least so many tokens as is the weight of the 
arcs from the place to the transition. An enabled transition may be fired and enable all 
the actions in the output places of the transition. There is a nondeterministic choice 
between the enabled transitions. Firing a transition modifies the markings of both input 
and output places. This may enable or disable other transitions. All enabled transitions 
may be fired. Therefore the evolution of the net describes a marking net which can 
be infinite. When a transition is fired, one token is removed from every input place 
of the transition and one token is added to every output place of the transitions. This 
is generalized by removing (resp. adding) the number of tokens corresponding to the 
weight of the arcs from the input place to the transition (resp. to the weight of the arcs 
from the transition to the output place). 

2.2 An Overview of B Abstract Systems 

An abstract system fl'31 describes a mathematical model of a system behaviour'. It is 
mainly made of a state description (constants, variables and invariant) and several event 
description. While abstract machines are the basic structures of the earlier operation- 
driven approach of the B method, abstract systems are the basic structures of the so- 
called event-driven B, and replace abstract machines. Abstract systems are comparable 
to Action Systems ; they describe a nondeterministic evolution of a system through 
guarded actions. Dynamic constraints can be expressed within abstract systems to spec- 
ify various liveness properties [3 8|. The state of an abstract system is described by 
variables and constants linked by an invariant. Variables and constants represent the 
data space of the system being formalized. Abstract systems may be refined like ab- 
stract machines [8 2 1. 

Data of an Abstract System At a higher level an abstract system models and contains 
the data of an entire model, be it distributed or not. Abstract systems have been used to 
formalize the behaviour of vaios (including distributed) systems I1I7I8I2I . Considering 
a global vision, the data that are formalized within the abstract system may correspond 
to all the elem ents of the distributed system. 

' A system behaviour is the set of its possible transitions from state to state beginning from an 
initial state. 
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Events of an Abstract System Within B, an event is considered as in the approach of 
Action Systems, i.e. as the observation of a system transition. Events are spontaneous 
and show the way a system evolves. An event has a guard and an action. It may occur 
or may be observed only when its guard holds. The action of an event describes with 
generalized substitutions how the system state evolves when this event occurs. Several 
events can have their guards held simultaneously; in this case, only one of them occurs. 
The system makes internally a nondeterministic choice. If no guard is true the abstract 
system is blocking (deadlock). An event has one of the general forms (Fig. [0 where 



name = /* event name 7 

SELECT 

P(gcv) 

THEN 
END 

(SELECT Form) 



name = /* event name 7 

ANY bv WHERE 
p 

( bv,gcv) 

THEN 

GS(^ bv,gcv) 

END 
(ANY Form) 



Figurel. General Forms of Events 



gcv denotes the global constants and variables of the abstract system containing the 
event; bv denotes the bound variables (variables bound to ANY). P^bv.gcv) denotes a 
predicate P expressed with the variables hv and gcv; in the same way GS(bv.gcv) is a 
generalized substitution S which models the event action using the variables bv and 
gcv. The SELECT form is just a particular case of the ANY form. The guard of an 
event with the SELECT form is P{gcv)- The guard of an event with the ANY form is 

3{bv).P(bv,gcv)- 

Semantics and Consistency. An abstract system describes a mathematical model that 
simulates the behaviour of a system. Its semantics arises from the invariant and is guar- 
anteed by proof obligations (POs). The consistency of the model is established by such 
proof obligations: /) the initialisation should establish the invariant; ii) each event of 
the given abstract system should preserve the invariant of the model (one must prove 
these POs). The proof obligation of an event with the ANY form is: 

^{gcv) ^ P{hv ^gcv) ^ \G^{hv ^gcv)\-^i^gcv) 

where I{gcv) stands for the invariant of the abstract system. 

3 Embedding Petri Nets into Event-B 
3.1 Embedding techniques 

Embedding techniques are introduced in fsl and provide a methodology to reuse exist- 
ing logical frameworks for formal analysis. Embedding techniques are intensively used 
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for method integration and mechanization of notations (ETWT^. There are two main 
embedding techniques: shallow embedding and semantic embedding (also called deep 
embedding). The first technique deals with the translation of specifications (objects of a 
formalism) to semantically equivalent objects in the target formalism. Nevertheless, the 
mapping from the language constructs to their semantic representations is part of the 
metalanguage (support of the source language). In the case of semantic embedding, the 
complete semantics of a source formalism is translated into the target formalism: both 
syntax and semantics of the source language are formalized inside the target language 
logic. That means, the mapping from language constructs to their semantic represen- 
tations is part of the target language logic. Consequently, using semantic embedding, 
we do not need only the (semantic preserving) syntactic translation of the constructs 
but also the semantics to be translated into the target logic. The choice of one of the 
techniques depends on the envisaged goal. 

3.2 Embedding the Structure of Petri Nets within B 

Embedding the structure of a P-net into B (Fig. |2j consists in describing the graph 
associated to the P-net. The 4-tuple which describes a net N is encoded with the set 
of places (places), the set of transitions (transitions), and the two relations between 
places and transitions (places Before, places After). Additionally we have the marking 
functions for the places: mu. We also consider the weights of the arcs; they are natural 
number greater or equal to the unit. The input arc weights are described by the func- 
tion weightBefore. The output arc weights are described by the function weight After . 
Therefore some invariant properties may be added. This results in an event-less B ab- 
stract system (Fig.|2} which captures only the graph structure of a marked net {N , mu). 
It remains to deal with the behavioural semantics of the Petri net. This is based on the 
marking of the net and the transitions. 

3.3 Embedding Petri Nets Evolution Semantics into B 

A P-net evolves by firing the enabled transitions. From a given marking, firing one of 
the enabled transitions, leads to a new marking of the net and so on. This is embedded 
in event-B by an abstract system whose events correspond to the transition firing. 

A P-net transition may be formalized (at first approximation) as a B event (see 
Fig. 13 with a guard which expresses that all the input places of the transition have the 
required number of tokens and a body (a generalized substitution) which expresses the 
update of input places (by removing the necessary tokens) and the update of output 
places (by adding the appropriate number of tokens). B events are instantaneous and 
their effect can cause the occurrence of other events. This copes well with the semantics 
of P-net: the firing of a transition ti is instantaneous and thus can lead to the firing of 
other transitions which have the output places of ti among their input places. 

Basic Petri net Here basic Petri net means that actions (data-noperations) are not at- 
tached to the places nor to the transitions. The arc weight may be greater or equal to the 
unit. The guard for firing a transition is that all its input places have the required number 
of tokens: Vp G placesBefore{t). fi{p) ^ ■weightBefore{t, p). The effect of firing a 
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SYSTEM PetriNet 




SETS 




PLACE; TRANSITION 




VARIABLES 




places, transitions , placesBefore, placesAfter, weightBefore, weightAfter, mu 


INVARIANT 




places C PLACE 




A transitions C TRANSITION 




A placesBefore £ transitions ■<-> places 


/* placesBefore ^ — Fp */ 


A placesAfter £ transitions places 


/* placesAfter — Ft */ 


A placesBefore = AoTa{weightBefore) 




A placesAfter = dom{weightAfter) 




A weightBefore G transitions x places -+ 


-> N 


A Aoxa{weightBefore) = placesBefore 




A weightAfter £ transitions x places ^ 


N 


A AoTa{weight After) = placesAfter 




A mti : places N 





Figure!. A Partial B system encoding a P-net 



transition is the update, via the /i function, of the input and output places according to 
the input and output arcs: 

Vp G placesBefore{t). fi{p) := ^{p) — weAghtBefore{t,p) 
Vp e places A fter (t). ii{p) + weAght After {t,p) 

Therefrom, the firing of a transition ti is translated with a single B event event_tr 
(Fig. |3} which works for every transition ti in a nondeterministic way. The variables 
mupbef and mupaft model with B generalized substitutions the update of the /i func- 
tion as described above. The notation s<\r expresses the restriction of the domain of the 
relation r to the elements in the set s. Likewise <f denotes the overriding of a relation 
by another one. 

To simplify the reading, we take some freedom with the notation of the abstract systems 
given in the remainder of the article. 

We captured the behavioral semantics of basic P-nets with a B abstract system with 
a single event representing the transitions of the net. This abstract system simulates the 
evolution of the P-net. Using a single event for all transitions instead of one event per 
transition simplifies the generalisation and the reasoning on the embedding; indeed only 
the structure of a parameter P-net needs to be translated for each new project. 

Generic Structure of the Embedding We show in Figure 0] the B generic structure 
which holds all P-net model; it is the abstract system named EmheddedPN . We separate 
the encoding of the semantics {EmheddedPN) which works for any P-net and the static 
structure part {PetriNet) which is specific to a problem and should be included for a 
given problem. The static part (in the PetriNet abstract system) is increased with some 
variables: pl_actions is the set of actions attached to the places. The injective (total) 
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event_tr = /* for any transition t, 7 

ANY U, pbef, paft, pb, vv, pa, uu, mupbef, mupaft, ■ ■ ■ WHERE 

pbef — placesBefore[{ti}] A paft = places After[{ti}] 
A mupbef £ places — > NAT A mupbef C mu A dom{mupbef) = pbef 
A pb e pbef A w G NAT 
A vv + weightBefore{ti,pb) < MAXINT 

A {{{pb, vv) £ mupbef) =J> {pb € pbef A {pb, vv + weightBefore{ti, pb)) G {pbef <1 mu))) 

A mupaft G places NAT A mupaft C m« A dom{mupaft) = pa/t 

A pa G pa/f A uu £ NAT 

A uu — weightBefore{ti, pa) > 

A {{{pa, uu) G mupaft) => (pa G pa/t A (pa, mm — weightAfter{ti , pa)) G (pa/i < mu))) 

A ■■■ 

THEN 

/* update the places before and after the transition t_i */ 
mu ~ mu <^{mupbef U mupaf) 
II ... 

END 



Figures. A shape of a B event capturing the evolution of a basic P-net 



function- pl_treatment G places pl_actions records the action located in each 
place; a specific element nullaction is used for the initialisation and for action-less 
places. 

The system EmbeddedPN has two variables: the relation trans_places records, for the 
currently fired transition(s), the output places which are not yet processed; the function 
guard_P_actions is used to get the guard of each place action. 

The single event event_tr manages the firing of transition and thus the evolution 
of the considered net. This event is improved and replaced in the following sections by 
two (or several events according to the considered policy) related events (action _ak, 
f ire_transition). 

Therefrom we extend the embedding to cover more complicated cases: action man- 
agement. Indeed, according to their types (place/transitions, conditions/event, resources, 
etc), P-nets may deal with data and actions (or treatments) in different manners. 

In some P-nets the places with tokens may model availability of data; in this case 
an action may be associated to the transition. In other models, some places may contain 
action which is then guarded by one or several transitions. It is for instance the case in 
a net modelling a process writing some data in exclusion with other writer processes; a 
specific place is often used in such a case (see Fig.|5](a)). Therefore there is not a single 
way to embed the P-nets. We investigated both cases of action attachment: to the places 
(e.g. writing, see Fig|5](a)) and to the transitions (e.g. Tl, T2, see Fig.|5](b)). 



^ It is injective because we need the reverse function. 



8 



SYSTEM EmbeddedPN 
INCLUDES 

PetriNet /* any described P-net; this is a parameter */ 
VARIABLES 

guard_P ^actions , trans_places 
INVARIANT 

guard_P ^actions G pl_actions BOOL 
A trans_places £ transitions ^ places 
INITIALISATION 

guard_P_actions := {{pl_actions — {nullaction}) x {FALSE}) 
\j{{nullaction, TRUE)} 
\\ trans_places :— {} 
EVENTS 

event_tr= ■■■ /* for any transition ti 7 

END 



Figure4. Generic Structure of the Embedding 




Figures. Places with associated action 



3.4 Dealing witli Non-Basic Nets 

In the previous section, we considered the evolution of basic P-nets; no specific policies 
or treatments are considered. 

High Level Petri Nets High Level Petri Nets (HLPN) were introduced to overcome the 
problem of the explosion of the number of elements needed for large computer systems. 
HLPN use i) structured data to model the tokens, and algebraic expressions to annotate 
the net elements; ii) transition modes to describe more elaborated operations/actions. 
Within HLPN the enabling of a transition depends not only on the availability of the 
tokens but also on their nature. There are several achievements of HLPN 1 13 1; 
Predicate/Transition-Nets |9| and Colored Petri-Nets P12I151 are two forms of HLPN. 
In this article, we consider an abstraction of the ideas of HLPN. Actions (treatments or 
operations) may be associated to places and transitions of the nets. This corresponds 
to the idea of structured tokens, typed places and typed transitions, and more generally 
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the execution of some operations associated to the places or to the transitions of a net. 
Accordingly, we have a generic treatment of the whole. 

The study is achieved step by step; first we examine the formalisation in the case 
where actions are associated to places only. Then we study the cases where they are 
associated to transitions. Finally we consider the general case where actions are associ- 
ated to both the places and the transitions. 

Petri Nets with Actions Attaclied to Places The actions attached to the places should 
be achieved when the places are guarded by a transition which is fired. Thereby each 
action in a place of a P-net is translated as a (guarded) event of the B abstract system. 
In practice, actions need some time to be completed. Therefore firing a transition may 
be achieved in two steps: i) enabling the guard of all the actions attached to the output 
places of the transition; ii) launching nondeterministically these involved actions. All 
of them should be performed in any order. 




Figure6. Interdependent Actions 



This raises some questions: what about the duration of the actions and the enabling 
of other transitions? Should we wait for the completion of an action before consider- 
ing another action? What about the scheduling of the enabled transitions and enabled 
actions? Considering these questions with respect to Figure|6lgives an idea of the com- 
plexity of the scheduling of actions; the transition tl enables the actions {A2, A3}; t2 
enables the actions { A4, Al }; t3 enables the action { A6 }; t4 enables the action {A5 }. 
These actions are interdependent because the places that contain them are either an in- 
put place or an output place of the fired transitions. There are cycles; for example, firing 
repeatedly the transitions t3 and t4. 

To deal with the current situation, we use the previously defined (see Section l33t vari- 
ables pl_treatment, pl_actions, guard— P— actions. The firing of a transition ti is han- 
dled with two events which correspond to the two steps distinguished above. 
The first step of the transition firing is captured with the B event fire_transition_tr 
given in Figure0 The output places of a transition U are: paft = places After[{ti}]. The 
involved actions associated to these places are: involved— actions = paft<]pl_treatment 
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The guards of the involved actions attached to the output places of the fired tran- 
sition are enabled (V Ai e places A fter[{ti}]. guard (Ai) :— true). The function 
guard_P_actions is updated in order to enable the guards. This is done with a Carte- 
sian product: ran{involved_actions) x { TRUE}. The marking of the input places is 
updated. The fired transition and its output places are recorded in the relation trans_places ; 
this is necessary for the scheduling of involved actions. Indeed all the actions of the out- 
put places should be performed before the actions of the possible transitions they can 
enable. 



fire_transition_tr = /* for any transition ti */ 

ANY tri, pbefs, pbef, mupbef , pa, vv, ■ ■ ■ WHERE 

pbefs — placesBefore[{ti}] A paft — placesAfter[{ti}] 
A pbef — {pic I pic G pbefs A mu{plc) ^ weightBefore{ti, pic)} 
A involved_actions = paft <i pl_treatment 
A ■■■ 
THEN 

guard_P_actions ~ ran{involved_actions) x {TRUE} 

/* enabling the guard of involved actions */ 
II mu :— mu <f mupbef 

/* update only of the input places of U */ 
II trans_places := trans— places U {{ti} x paft) 

/* the output places of ti ; they will be updated later on */ 

END 



Figure?. Dynamic part of the generic structure (a) 



Since the B events are atomic we cannot update the marking of output places during 
the first step; they will eventually enable other transitions which will take place. More- 
over, to cope with practical application of P-nets, one has to consider the "run until 
completion" of the various actions during their scheduling. 

The second step of the firing is captured with the event action_Ak (see Fig.|8}. 
One B event is described for each action associated to a place. This enables us to handle 
the high level aspect of the net; indeed the treatments depend on the tokens and on the 
transitions. The guard of each action is maintained until the action is performed. The 
actions attached to the output places which are still enabled, are nondeterministically 
performed; they are recorded in (the range of) trans— places. But, the actions in the 
places contained in trans_places can be performed at any time (due to the nondeter- 
minism of event occurrence). When an action is completed its guard is disabled and the 
number of tokens of the place is updated: the function trans— places is updated, the mu 
function is updated to set the marking of output places. 

However, there are some shortcomings with the current case. There is a kind of 
loss of priority between actions: if the effect of one of the currently enabled actions 
contributes to fire another transition, the actions enabled by this latter transition can be 
performed before the actions already enabled (this comes fatally from the substitution 
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action^Ak = /* for an action Ak (attached to a place pp) 7 

ANY pp, tr, wetga, ■ ■ ■ WHERE /* pp is tlie place of the action Ak 7 

pp e PLACE A pp ^ pl_treatment~^ (Ak) 
A guard-P -actions {Ak) = TRUE 
A {tr,pp) € trans-places 
A weiga = weight After {tr, pp) 
A ••• 
THEN 

• • • /* place to put an effective action Ak 7 

guard-P-actions{Ak) := FALSE 

II mu{pp) :— mu{pp) + weiga 

II trans_plac.es := trans_plac.es — {(tr,pp)} 

hND 



Figures. Dynamic part of the generic stracture (b) 

trans_places := trans_places U {{U} x paft)). 

Another shortcoming is the following: when there are cycles, an enabled guard (of an 
action) can be overwritten; that is, the enabUng condition can be observed again whereas 
the already enabled action is not yet performed. 

We solve these problems in the general case presented later on, by using priorities. 

Petri Nets witli Actions Attaclied to Transitions In the same way as for the previous 
case with places, a total function tv-treatment e transitions tr-actions records 
the action associated to each transition. 

tr-actions is the set of actions attached to all the transitions; it is defined in the static 
structure (PetriNet). When an enabled transition is fired, its associated action should 
be performed before the update of the marking of the output places, otherwise another 
transition may take the priority over the current. 

Several transitions may share the same input place(s). But, when the latter has the nec- 
essary number of tokens to enable the transitions which share the place, only one of the 
enabled transitions is fired. Therefore two steps are necessary to handle the firing of a 
transition. In a first step, one of the enabled transitions is nondeterministically selected; 
the guard of the action associated to this transition is enabled. The marking of all the 
input places is updated. This is quite similar to the event fire_transition_tr. In a sec- 
ond step, the transition action is performed; its guard is disabled and, the marking of 
the output places is updated. These places may enable other transitions and so forth. We 
get two B events corresponding to the described steps: i) a firing event which is used 
to select a transition and to update the input places; this event deals with all the en- 
abled transitions; ii) each transition action has an event with its associated guard which 
depends on the marks of input places. 

Petri Nets witli Actions Attaclied to botli Places and Transitions In the current case, 
when a transition is fired, the action linked with it is enabled and the marking of the out- 
put places of the transition is updated; these output places have actions which should 
be enabled. After that, the transition action is performed, it enables the actions linked to 
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the output places. Moreover, the action linked to the places should be performed before 
enabling the transitions linked to them. In order to embed this semantics, we use addi- 
tionally with the preceding variables, the function enabled— P —actions for the currently 
enabled place actions; enahled_T —actions for the currently enabled transition actions. 
We remind that trans— places records which output places are not yet processed for the 
currently fired transition. 

The embedding is achieved according to priority rules. The priority between actions 
are handled as follows. A transition is fired if i) the input places have the required 
number of tokens, it) there is no previous enabled place action not yet performed; this 
is checked with {trans_places = {}). Indeed when a transition is fired, its action is 
enabled and it enables some (output) place actions. They all should be performed before 
firing another transition. This policy solves the problem of guard overwriting. 

Therefrom the event fire_transition_tr is modified as described in Figure|9l 



flre_transition_tr = /* for any transition ti */ 

ANY ti, pbefs, pbef, mupbef , pa, vv, - ■ ■ WHERE 

pbefs = placesBefore[{ti}] A paft = placesAfter[{ti}] 
A pbef — {pic I pic € pbefs A mu{plc) ^ weightBefore{ti, pic)} 
A trans_places = {} A (enabled_P_actions > { TRUE }) ={} 

A involved_actions = paft <i pl_treatment 

A ■■■ 

THEN 

enabled_T_actions{U) := TRUE 

I* enabling the action of the transition */ 
II enabled_P_actions := ran{involved_actions) x {TRUE} 

I* enabling the guard of the involved place actions */ 
II mu :— mu <+mupbef I* update of the input places of ti */ 
II tranS— places := {t;} x paft 

I* get the output places of ti ; they will be updated later on */ 

END 



Figure9. Dynamic part of a Petri Net with Place and Transition Actions 



The remaining accompanying events (not detailed here) are the following: 
enable_transition_action_guard; it sets the guard of an enabled transition action to 
TRUE, then it disables the transition guard. 

enable_place_action_guard; it sets the guard of an enabled place action to TRUE, 
updates the mu function and updates trans_places by removing the treated place; 
launch_transition_action^j; it launches one of the transition action whose guard is 
true and then it sets the guard to false; 

launch_place_action_ak; this one launches a place action whose guard is enabled, 
then the guard is disabled. 

All these five events (of the abstract system EmbeddedPN) simulate an interleaving 
run of the firing of transition actions and place actions, but priority is employed to avoid 
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bad behaviour of the actions. The entire system is checked for consistency using Atelier 
B; some analysis issues are considered with various case studies. 

4 Analysis Issues 

4.1 Analysis of Petri Nets 

Very often, two classes of properties are studied on P-nets: one is about the boundedness 
of the nets. For example the accumulation of tokens in a place is symptomatic of a bad 
functioning of a model. The second class is about the liveness of the nets. By studying 
the reachability of certain marking, one can detect deadlock freedom for example. In 
all these cases, the marking graph (the set of reachable markings) should be computed. 
This aspect of the analysis may raise some problems. The size of the graph may be too 
large to be analysed in a reasonable time; the graph may also be infinite. When the graph 
is infinite, a covering graph is used; it enables to check a part of the desired properties. 

Three main class of analysis techniques 1 17 191 for P-nets are: 
Reachability analysis: it is based on state space exploration/reduction techniques using 
model checking. The main idea is to construct an occurrence graph (a directed graph) 
which has a node for each reachable system state (a marking) and an edge for each 
possible state transition. The analysis is then based on such graph. 
Reachability is like a simulation of the modelled system execution. It allows for a rapid 
analysis of the system to check for its functionalities. 
Structural analysis: algebraic analysis are applied here. 

Invariant analysis: it consists to check that some properties associated to the places are 
satisfied for all reachable states (a net marking) of the modelled system. 

The advantages of the first analysis techniques are: a graph is constructed and anal- 
ysed systematically; the constructed graph may be very large; but it exists techniques 
which makes it possible to work with minimized graphs. However the main disadvan- 
tage is that, such a graph may become very large, even for very small systems, rending 
the analysis unpractical due to state explosion problem. 

One of the aspects on which this work contributes in is the definition of the basis 
for the combined use of analysis techniques and tools. The available B platforms may 
be used to analyze the safety properties of systems which are modelled with P-nets. 

4.2 An Illustration: Producer-Consumer with Semaphore 

We described and checked the producer-consumer system depicted in Figure ^| us- 
ing our approach. Only the description of the abstract system PetriNet is given; it is 
included in the system EmbeddedPN which does not change (it gathers the P-nets se- 
mantics). Additionally to the properties that may be analyzed in a standard Petri-net 
platform, some safety properties that may be analysed using the B tools are: 

- Boundedness of some places: the places Empty _buf and D_in_buf (see Fig. I10> 
are bounded. This is formalized as the following predicate which is added to the 
invariant: 

mu{Empty_buf) ^ 2 A mu{D_in_buf) ^ 2 

- There is not a bad usage of the resources (here the buffer): 

mu{Empty_buf) + mu{D_in_buf) — 2 
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FigurelO. A producer consumer example 



- The system is live; that means there is always at least one transition which can be 
fired; this is formalized with: 

places Bef ore ~[dom{nmu [> {ii \ ii £ N A ii > 0})] ^ {} 

This illustrates how we may manage the modelling and analysis work through Petri- 
nets and B. We achieved some experiments with such properties. In the current article, 
due to lack of space we do not go into the details of this analysis aspect. 

5 Conclusion and Further Work 

We presented an embedding of Petri nets formalisms (and modelling) into the B abstract 
system formalism. The embedding is systematic and it covers basic P-nets as well as 
high level nets. The current work fills a gap between the widely practiced P-nets formal- 
ism and the emerging proof-based development technologies especially the B method 
which is based on abstract machines, refinement and theorem proving. That is a step 
towards a multi-facet analysis framework for relating discrete system modelling tech- 
niques. 

Results. We provide a two-level embedding infrastructure made of a generic B abstract 
system that may be used to describe any Petri-net and, an abstract system that includes 
(genericity) the first one and whose events capture the semantics of Petri-nets evolution. 
Various policies concerning high level P-nets have been considered. Concretely we may 
combine the use of P-nets and B method in the same project; for example we may begin 
the modelling with an existing graphical tool dedicated to the P-nets and then follow 
with the B method for some related aspects. This work is generally related to works on 
embedding techniques but it is specifically related to the work by Sekerinski and Zurob 
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1201 on Statecharts and B. 

Further work. Ongoing effort focuses on the automation of all the chains from a P-Net 
tool to the B tools. We investigate the transformation into a B machine, of the XML 
outputs of the tools such as the PEP tool ^ . The result is to be passed as the included 
machine. But, many experiments of various size are still needed for the scalability of 
our translation process. Meanwhile, user-friendly tools to facilitate the combination of 
the techniques are of a major interest. 
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